\section{A metamodel-independent approach to uncertainty}\label{sec:metamodel}
\vspace{-0.2cm}
Uncertainty as it is known in literature (e.g.,~\cite{FSC12}) does not have a characterization in terms of metamodels. It is mainly based on annotations which can be processed by tools which are outside, for instance, the EMF ecosystem. 
In this section, we introduce a metamodel-independent approach to uncertainty representation, i.e., starting from a \emph{base} metamodel
$M$
we are interested in understanding what are the characteristics of the corresponding metamodel with uncertainty 
$U(M)$ 
and how constructively define it. Since, it has to be used in modeling environment and must be processed by means of automated transformation, it is important that any possible candidate will satisfies the following requirements

\begin{itemize}
\item[--] \emph{model-based}, a set of models representing different alternatives must be represented with a model with uncertainty enabling a range of operations, including analysis or manipulations during the decision process;

\item[--] \emph{minimality}, a model with uncertainty is a concise representation of all the alternative solutions; it should not contain any other information besides what needed for representing both the common elements and alternative elements, i.e. alternative designed choices grouped by a point of uncertainty;

\item[--] \emph{metamodel-independence}, the metamodel must be agnostic of the base metamodel, i.e., it must be defined in a parametric way such that the definition procedure can be applied in an automated way to any metamodel;

\item[--] \emph{interoperability}, each model containing uncertainty must be applicable an unfolding operation, such that whenever applied to it returns all the correspondent concretizations models or the specific concretization selected by the designer.
\end{itemize}
%
Starting from these requirements, an automated procedure
$
U:\emph{Ecore}\to\emph{Ecore}
$
written in ATL is proposed. The transformation takes any Ecore base metamodel $M$ and returns the corresponding metamodel with uncertainty $U(M)$ as described in the rest of the section. 

\vspace{-0,2cm}
\subsection{The uncertainty metamodel}\label{sec:UMM}
The metamodel with uncertainty is obtained by extending the base metamodel with given connectives to represent the multiple outcomes of a transformation (as showed in Sect.~\ref{sec:jtl}). These connectives denote points of uncertainty where different model element are attached. Moreover, such points of uncertainty are traceable in order to ease the traversal of the whole solution space and permit the identification of specific concretizations. 

As an example, let us consider \emph{HSM}, the metamodel of the hierarchical state machines given in Fig.~\ref{fig:HSM}. Then the corresponding metamodel with uncertainty $U(\emph{HSM})$ illustrated in Fig.~\ref{fig:UHSM} can be automatically obtained as follows:
%
\begin{itemize}
\item[--] the abstract metaclass \code{TracedClass} with the attributes \code{trace} and \code{ref} are added to $U(\emph{HSM})$;
\item[--] for each metaclass \emph{c} in \emph{HSM}, such that it is non-abstract and does not specialize other metaclasses, \emph{i)} a corresponding metaclass \emph{uc} is created in $U(\emph{HSM})$ such that \emph{uc} specializes \emph{c}, and \emph{ii)} \emph{c} is generalized by \code{TracedClass};
\item[--] each metaclass \emph{uc} is composed with \emph{c}, enabling the representation of a point of uncertainty and its alternatives;
\item[--] the cardinality of attributes and references derived from \emph{HSM} are relaxed and made optional in $U(\emph{HSM})$ in order to permit to express uncertainty also over them. 
\end{itemize}
%

\vspace{-1cm}
\begin{figure*}[ht]
   \center
    \includegraphics[width=12cm]{figures/HSM2.jpg}
    \vspace{-0.2cm}
    \caption{The \emph{HSM} metamodel}
    \vspace{-0.5cm}
      \label{fig:HSM}
\end{figure*}
\vspace{-0.1cm}
%  
In particular, the metaclasses \code{UStateMachine}, \code{UState} and \code{UTransition} in $U(\emph{HSM})$ derive from \code{StateMachine}, \code{State} and \code{Transition} in \emph{HSM}, whereas the latter ones are generalized by \code{TracedClass}. The scope of this abstract class is to maintain information about the relationships between the points of uncertainty and the correspondent own alternatives in the concretization models. The role of the attributes \code{trace} and \code{ref} of \code{TracedClass} will be discussed in Sect.~\ref{sec:jtl-gen-un}.
%
\vspace{-0.5cm}
 \begin{figure*}[ht]
   \center
    \includegraphics[width=10cm]{figures/UHSM2.jpg}
    \vspace{-0.4cm}
    \caption{The $U(\emph{HSM})$ metamodel}
    \vspace{-0.6cm}
      \label{fig:UHSM}
 \end{figure*}
 
As said, the above procedure is implemented as an endogenous model transformation in ATL. For the sake of brevity, only an excerpt of the transformation is presented in Listing~\ref{lst:ATLMM2UMMtransf}\footnote{The \emph{MM2UMM} transformation implementation is available at http://jtl.di.univaq.it/} containing solely those rules which build the specific constructions of the uncertainty metamodel. More in detail, the rule \code{EClass2UEClass} (lines 20-36) \emph{a)} propagates base metaclasses (and their associations) which are not  abstract and do not have non-abstract ancestors (lines 21-22) and \emph{b)} for each of them generates a corresponding uncertainty metaclass (lines 27-30), as in Fig.~\ref{fig:UHSM} where the metaclass \code{UState} is generated and composed with \code{State}.  Moreover, the target pattern (lines 23-36) is composed of a set of elements, each of them  specifies a target type from the target metamodel and a set of bindings. In particular, the element \code{t} (lines 23-26) copies the metaclass \code{s} in the target metamodel; the element \code{u} of the target pattern (lines 27-30) generates uncertainty metaclass as specialization of the matched source class \code{s}; and finally, the reference \code{r} is created as a structural feature of the element \code{u} in order to refer alternative elements contained in \code{u}. 



\begin{lstlisting}[breaklines,style=AMMA,language=ASPencoding,mathescape,rulesepcolor=\color{black},caption={ A fragment of the MM2UMM transformation},captionpos=b, aboveskip=0.2cm, belowskip=0.5cm, label={lst:ATLMM2UMMtransf}]
module MM2UMM;
create OUT : UMM from IN : MM;
entrypoint rule Metamodel() {
	to tr : UMM!EClass (
			name <- 'Traceable',
			"abstract" <- true,
			eAttributes <- Sequence{}->append(att)->append(ref)),
		att:UMM!EAttribute (
			name <- 'trace',
			eType <- thisModule.eStringType),
		ref:UMM!EAttribute (
			name <- 'ref',
			eType <- thisModule.eObjectType,
			lowerBound <- 0,
			upperBound <- -1)
	do {
		thisModule.traceableMetaclass <- tr;
	}
}
rule EClass2UEClass {
    from s : MM!EClass ((thisModule.inElements->includes(s)) and
        ((s.eSuperTypes->size()=0) or (s."abstract"='false')))
    to t : UMM!EClass (
        name <- s.name,
        eSuperTypes <- s.eSuperTypes->append(thisModule.traceableMetaclass),
        ...),
    u : UMM!EClass (
        name <- 'U'+s.name,
        eReferences <- Sequence{}->append(r),
        eSuperTypes <- Sequence{}->append(s)),
    r:UMM!EReference(
        name <- s.name + 's',
        containment <- true,
        lowerBound <- 1,
        upperBound <- -1)
}
rule EReference {
    from s : MM!EReference (thisModule.inElements->includes(s))
    to t : UMM!EReference (
        name <- s.name,
        lowerBound <- 0,
        ...)
}
\end{lstlisting}
%
To better understand how a point of uncertainty is realized, please consider the alternative solutions in the right-hand side of Fig.~\ref{fig:HSM2SMmodels2} and how they are denoted by the corresponding point of uncertainty illustrated in Listing~\ref{lst:xmi} given in the XMI\footnote{http://www.omg.org/spec/XMI/} format.
%
\begin{lstlisting}[breaklines,style=AMMA,language=ASPencoding,mathescape,rulesepcolor=\color{black},caption={ An uncertainty model fragment},captionpos=b, aboveskip=0.2cm, belowskip=0cm, label={lst:xmi}]
[...]
<ownedTransition xsi:type="UHSM:UTransition" name="">
    <transitions trace="15,x/15" trigger="print" target="//@ownedState.3"
        source="//@ownedState.2/@ownedSubState.0" name="print">
      <ref href="HSMm_1.xmi#/"/>
    </transitions>
    <transitions trace="15,x/15" trigger="print" target="//@ownedState.3"
        source="//@ownedState.2/@ownedSubState.1" name="print">
      <ref href="HSMm_2.xmi#/"/>
    </transitions>
    <transitions trace="15,x/15" trigger="print" target="//@ownedState.3"
        source="//@ownedState.2/@ownedSubState.2" name="print">
      <ref href="HSMm_3.xmi#/"/>
    </transitions>
    <transitions trace="15,x/15" trigger="print" target="//@ownedState.3"
        source="//@ownedState.2" name="print">
	     <ref href="HSMm_4.xmi#/"/>
    </transitions>
</ownedTransition>
[...]
\end{lstlisting}

\vspace{-0.4cm} 
\subsection{Operators}

%{\bf Gli operatori servono per garantire interoperability (R4) e per consentire ai designers di gestire/operare su modelli con incertezza e relative concrs}

Once the uncertainty metamodel $U(M)$ is automatically defined starting from the base metamodel $M$, it is important to achieve a complete interoperability between the base and the uncertainty metamodels as required in Sect.~\ref{sec:metamodel}. To this end, the following operators have been defined.

\vspace{-0.3cm} 
\subsubsection{Concretization operator.} This operator is defined in order to return all the concretizations represented in a model with uncertainty. More formally, the concretization operator \emph{concr} is a mapping defined for any base metamodel $M$  
\[
\emph{concr}: U(M)\to M^*
\]
which takes an arbitrary model with uncertainty $\bar{m}\in U(M)$ and returns its $k$ concretizations $\langle m_1 \cdots m_k\rangle\in M^*$. 

By entangling the uncertainty with the specialized metamodel construction $U(M)$, it is of crucial relevance to be able to retrieve the concretizations as instances of their base metamodel. As one can expect, the reasons why this is important can be numerous including the necessity to keep on exploiting, utilizing, and capitalizing on existing tools. When a JTL transformation is executed, the engine deduces simultaneously both the solution space and the corresponding model with uncertainty. For instance, the outcome of the \emph{concr} application to the model in Fig.~\ref{fig:UHSM} corresponds to the models in the right-hand part of Fig.~\ref{fig:HSM2SMmodels2}.

\vspace{-0.2cm} 
\subsubsection{Refinement operator.} Whenever a model with uncertainty is obtained, it is important to refine it according to a given property. The \emph{refine} operator is a mapping
\[
    \emph{refine}:\emph{OCL}\times U(M)\to M^*
\]
%
that for any model with uncertainty $\bar{m}\in U(M)$ and OCL predicate $p_M$ defined over the metamodel $M$ returns a set of concretization in $M^*$ such that 
\[
    \emph{refine}(p_M,\bar{m}) = \{m\in\emph{concr}(\bar{m})|m \models p_M\}
\]
The intention is to reduce the uncertainty by removing those concretizations which are not satisfying a given predicate, i.e.  
\[
    \emph{refine}(p_M,\bar{m})\subseteq\emph{concr}(\bar{m})
\]
As said, the refinement is intended as a filter applied on the whole solution space in order to perform a fine-grained removal of certain concretizations which can be not desired and anyhow present among the concretizations of the model with uncertainty. Clearly, the \emph{concr} can be seen as a special case of \emph{refine} with a \emph{true} predicate. For the sake of clarity, we preferred to keep these two operators distinguished. An application example of the \emph{refine} operators is illustrated in Sect.~\ref{sec:jtl-gen-un}. 

 \vspace{-0.3cm}
\begin{figure*}[ht]
   \center
    \includegraphics[width=11cm]{figures/uncertainty_xmi.jpg}
    \vspace{-0.2cm}
    \caption{UHSMm model}
    \vspace{-0.2cm}
      \label{fig:UMHSM}
 \end{figure*}
  \vspace{-0.4cm}

%For instance, 
%the following predicate
%\begin{lstlisting}[breaklines,style=AMMA,language=ASPencoding,mathescape,rulesepcolor=\color{black}, numbers=none]
%Transition.allInstances()->collect(e | e.transitions)->select(e:Transition | e.source.isInstanceOf( State ))                              
%\end{lstlisting} 
%when referred to the model with uncertainty in Fig.~\ref{fig:UMHSM}, permits to \emph{refine} the solution space in such a way only transition whose source is a {\small\tt State}.

\medskip\noindent
Both operators have been implemented in ASP. The implementation of the refine operator required the OCL embedding into ASP. Since OCL is more expressive than ASP, not all the predicates can be fully translated into ASP. However, if we restrict our attention to those predicates which refine the solution space by resolving the uncertainty points, then ASP provides enough expressiveness. Also, the ASP expressiveness can partly depend on the specific solver and in some cases enhanced expressiveness can be achieved by encoding the problem into a different solver. 
 

